perm filename RPG.MSG[BUG,LSP] blob
sn#397383 filedate 1978-11-21 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00050 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00006 00002 ∂04-Feb-77 1522 RPG
C00007 00003 ∂07-Feb-77 1537 RPG
C00008 00004 ∂16-Feb-77 1419 FTP:GLS at MIT-MC (Guy L. Steele, Jr. ) The nefarious GC-OVERFLOW during FASLOAD problem
C00011 00005 ∂07-Mar-77 1147 FTP:MASINTER at PARC-MAXC Re: Lisp Wizardry
C00014 00006 ∂09-Mar-77 0030 FTP:Boyer at SRI-KL Stack Crawler
C00017 00007 ∂11-Mar-77 1722 RPG
C00018 00008 ∂18-Apr-77 1526 RPG maclsp
C00019 00009 ∂19-May-77 0148 JJ
C00024 00010 p07-Jun-77 1458 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
C00026 00011 ∂30-Jun-77 1509 RPG
C00027 00012 ∂03-Jul-77 1745 LIS NEW PSI.SAV AT ISIC
C00029 00013 ∂06-Jul-77 1540 RPG %cxr
C00030 00014 ∂12-Jul-77 1311 JP here it is: FASFRKs!!
C00032 00015 ∂20-Jul-77 1652 LIS via ISIC MAKING YOUR OWN MACROS IN INTERLISP
C00033 00016 ∂20-Aug-77 0535 FTP:PRATT at MIT-AI (Vaughan Pratt)
C00037 00017 ∂06-Sep-77 1407 PAM
C00038 00018 ∂14-Sep-77 1249 RPG
C00039 00019 ∂23-Sep-77 1422 FTP:GLS at MIT-AI (Guy L. Steele, Jr.)
C00040 00020 ∂22-Oct-77 1749 RPG hunks
C00041 00021 ∂24-Oct-77 1337 RPG
C00042 00022 ∂27-Oct-77 1346 BPM Guidelines for use of ISIE
C00044 00023 ∂28-Oct-77 0148 RPG READ6C
C00045 00024 ∂28-Oct-77 0901 BPM Changing passwords at ISIE
C00046 00025 ∂02-Nov-77 1616 JP MACLSP meta-D directory feature
C00048 00026 ∂03-Nov-77 1215 FTP:DEWOLF at WPAFB-AFAL Change of address
C00051 00027 ∂08-Nov-77 1117 WLS EDIT loss
C00053 00028 ∂23-Nov-77 2025 FTP:gls@ai RABBITy things
C00055 00029 FASLAP/NCOMPL
C00056 00030 ∂02-Dec-77 1443 FTP:DEWOLF at WPAFB-AFAL ATN stuff
C00063 00031 AT gethgh+16 jrst patch
C00064 00032 ∂12-Dec-77 1333 FTP:DEWOLF at WPAFB-AFAL
C00065 00033 ∂15-Dec-77 1907 DCO datamedias
C00066 00034 ∂21-Dec-77 0312 JJ
C00068 00035 ∂19-Dec-77 1259 RPG fx arrays
C00069 00036 ∂20-Dec-77 1445 RPG
C00070 00037 ∂05-Jan-78 2109 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) HISEG CRAP
C00072 00038 ∂14-Jan-78 1413 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) OS/S1 and LISP and others
C00077 00039 ∂09-Feb-78 1857 FTP:HIC at MIT-MC (Howard I. Cannon)
C00078 00040 ∂13-Feb-78 1455 CCG psi
C00080 00041 ∂23-Feb-78 1655 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) PRINTA
C00081 00042 ∂21-Mar-78 0002 JJ
C00082 00043 At ldrihs+5 =1447
C00083 00044 ∂07-May-78 0206 LIS NEW PSI
C00084 00045 ∂11-May-78 1847 RPG Fleming
C00085 00046 GLS@MIT-AI 05/27/78 17:09:59 Re: Cretinous Stack Groups
C00114 00047 ∂14-Jun-78 1442 LIS
C00115 00048 To make a directory at MIT do
C00116 00049 Date: 10 Oct 1978 0307-PDT
C00119 00050 ∂20-Nov-78 1157 RPG
C00120 ENDMK
C⊗;
∂04-Feb-77 1522 RPG
at ttyint+n trze a,600,trz a,100 → trz a,740 for g → ↑g in *lisp >
at sailp4 + n trz c,100 → trz c,140 for ↑q → ↑Q in alloc >
at alltyi - 1 tests for Q → ↑Q etc
∂07-Feb-77 1537 RPG
(SETSYNTAX 73 'SINGLE NIL) DOESN'T WORK.
∂16-Feb-77 1419 FTP:GLS at MIT-MC (Guy L. Steele, Jr. ) The nefarious GC-OVERFLOW during FASLOAD problem
Date: 16 FEB 1977 1720-EST
Sender: GLS at MIT-MC
From: GLS at MIT-MC (Guy L. Steele, Jr. )
Subject: The nefarious GC-OVERFLOW during FASLOAD problem
To: (BUG LISP) at MIT-MC
CC: rpg at SU-AI
Message-ID: <[MIT-MC].38475>
The source of this difficulty, which has been plaguing MACSYMA,
stems from a fix JONL installed for a bug to the effect that if
GC-OVERFLOW occurred, then the GC-DAEMON was not run for that GC.
The fix caused the GC-OVERFLOW to re-enter GC after the interrupt.
The problem is that if interrupts were locked out (during FASLOAD,
e.g., which must CONS with INHIBIT set for other reasons),
then several GC-OVWRFLOR interrupts could get stacked up in INTAR
before interrupts got unlocked.
I have elected to use a fix which causes GC-OVERFLOW not to
loop back into GC. The idea is to call UINT directly from
within GC when the overflow is detected. Since NOQUIT is set,
UINT will just stack the interrupt. Then we simply carry on,
and run GC-DAEMON if appropriate. (Actually, should
GC-DAEMON be run first or GC-OVERFLOW? Under this setup
the GC-OVERFLOW gets run first, since GCRSR does a CHECKI
before running the GC-DAEMON.)
One additional advantage of this scheme is that if several spaces
get a GC-OVERFLOW, we can give interrupts for all of them,
while formerly we gave an interrupt for only one.
A possible modification of this scheme is to cause a little
extra space to be allocated even if the GCMAX is exceeded
if INHIBIT is set. I don't think this will be necessary, however.
∂07-Mar-77 1147 FTP:MASINTER at PARC-MAXC Re: Lisp Wizardry
Date: 7 MAR 1977 1148-PST
From: MASINTER at PARC-MAXC
Subject: Re: Lisp Wizardry
To: RPG at SU-AI
cc: CCG at SU-AI
In response to your message sent 1 Mar 1977 1316-PST
In response to your message sent 1 Mar 1977 1316-PST
Cordell and I talked briefly about it; I think it is a great
idea. We had planned on talking to you about doing the course as well.
Maybe we should get together to talk about it.
Possible topics:
Lisp implementations:
methods of determining data-types (type tables, address boundaries,
type bits)
numbers (small numbers, numbers-on-the-stack), bignums
function linkage, compiler techniques, garbage collection
Programming tools in various lisps
(I'm most familiar with Interlisp here, of course) -- Im thinking
of the editor, history, dwim, masterscope, etc.
Organization of large lisp systems.
----------
I don't think people can write efficient code unless they have
some understanding of the implementation (or of the possible implementations)
of the code they are writting; that is why a large section
on implementation of Lisp.
We might have guest speakers? Make it a seminar, with people in
the class reporting? Have the class write a large lisp program
as part of the class?
Not sure about those things.
Larry
-------
∂09-Mar-77 0030 FTP:Boyer at SRI-KL Stack Crawler
Date: 9 Mar 1977 0032-PDT
From: Boyer at SRI-KL
Subject: Stack Crawler
To: rpg at SU-AI
You can put the files related to the stack crawler, or anything
else related to maclisp on the SRI-KL directory <maclisp>
password speed. You cannot log in as Maclisp though, so login
as me, password g9734 (Boyer, move your fingers up). You will
find on Maclisp a fairly large subset of the files related to
the Maclisp d10 system from mit-mc. Please observe the convention
of naming files that come from MIT with the obvious convention
we are using that preserves in the file version number some approximation
to the mit number. E.G. the first version of LISP.MID.1251 from MIT
would be our LISP.MID.125101.
(I forgot to say that when you log in as me you will need to give the
account CSL).
The Maclisp directory is controlled by DANG (Dan Gerson), who is
the person responsible for SRI's maclisp involvement. Please send
copies of messages to him. I understand you have been in touch with
him on the nasty question of moving the Maclisp D10 high seg
up from 400000 to around 600000, if possible, to alow TENEX and D20
users to have large lisps. That would sure be nice.
If you have any problems, you can come over to sri, talk to
me or dang if we are on, or call me at 326-6200 x4542, 324-8666,
326-5804, or 493-3135.
On the D20 one can define the device sys: to be what you want.
So when you login as me, you will automatically get the definition
define sys: (as) sys:, <maclisp>, <lisp>
This hack alows the autoload stuff to all work perfectly.
¬Thanks very much for you attention to our maclisp problems and for
your stack crawler and editor and anything you can send our way.
Bob.
-------
∂11-Mar-77 1722 RPG
A2TT +2 CAILE TT,300. → CAILE TT, 1000
∂18-Apr-77 1526 RPG maclsp
think about
uwrt0+4 skipn d10nam
pushj p, sixjbn
move t, d10nam
∂19-May-77 0148 JJ
-AN INCLINED LUMBAGO IS STRONGLY INDICATED-
possible slot names and their backpointers. In addition to the below,
there are, CLASS (value either ALG, DATA, or PRED) which indicates
the general type of the component. FTYPE which futher specifies the CLASS
If CLASS=ALG, then FTYPE can be SEQ, LOOP, COND, CASE, INPUT, OUTPUT etc
IF CLASS= DATA then FTYPE can be SET, ATOM, STRING, PLEX etc
IF CLASS=PRED, there is no FTYPE slot, but there is DEF slot which
holds the definition of the predicate.
The sematics for these can be found in T5[T,JJ] PAGE 3, LINE 73+
(the names in t5 are slightly different (eg EXITTEST → EXIT-TEST)
the ones below are from the program)
((CASES CASEOF)
(ARG1 ARG1OF)
(ARG2 ARG2OF)
(PARTS PARTOF)
(ARGS ARGOF)
(SETMEMBER SETMEMBEROF)
(EXITTEST EXITTESTOF)
(IARG IARGOF)
(MEMBERS MEMBEROF)
(SUBSETS SUBSETOF)
(INSTANCEOF INSTANCE)
(LABELOF LABEL)
(STEPS STEPOF)
(ELEMENT ELEMENTOF)
(NAME NAMEOF)
(TEST-RESULT TEST-RESULTOF)
(HAS-PROPERTY PROPERTY-OF)))
Current Question list. (will be expanded I handle different kinds of
dialogues and when the Dialogue expert gets around to asking stuff
like "what would you like to talk to about next"
X is a random component. Sometimes the question type places constraints
on X, eg, (PROMPT X) implies X is an INPUT component.
(STRUCTURE X)
(NAME X)
(I-VALUE X) "WHAT IS THE INITIAL VALUE OF X"
(ARGS X) "WHAT ARE THE ARGUMENTS OF X"
(PROMPT X) "WHAT IS THE PROMPT OF X"
(FORMAT X) refers to output format
(ELEMENT X) What are the elements of X
(PROGRAM-TYPE X) DOES X HAVE A SPECIAL PROGRAM TYPE
(DEFINITION X) refers to the defintion of a predicate X
(DESCRIBE X)
(VERIFY DONE) "ARE WE FINISHED" IE END OF DIALOGUE QUESTION
GO-ON "GO ON"; asked if user responds no to (VERIFY DONE)
(EXITTEST X)
I think this is all there is now, but...
Some questions can be preceeded by MODAL eg. (MODAL (PROMPT X))
which means the question should be phrased as "Should there be a prompt
for X" as opposed to "What is the prompt for X".
∂05-Aug-77 1615 JJ
here is a new question to chew on -- (WHAT-TO-DO-WITH X)
at the momment X can only be a result of a test. the suggested
interpretation is "what do you want to with ..." eg.,
PSI: ARE WE FINISHED?-
←
Then it tests whether the element is a member of the set
PSI: WHAT DO YOU WANT TO DO WITH THE RESULT OF THE TEST- ←←←←←←←←←←←←←←←←←←←←←
←
Then it prints out the result of the test
PSI: WHAT IS THE FORMAT OF THE OUTPUT?-
←
it prints "yes" if it is a member of the set and "no" if it isn't
PSI: ARE WE FINISHED?-
←
yes
PSI: OK-
∂09-Aug-77 1255 JJ
still another question to ...
(TOPLEVEL-OR-LOOP X Y)
should y be at the top level of x or in its loop?
------
x has a loop in its steps and y is the step just after it.
p07-Jun-77 1458 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
Date: 7 JUN 1977 1755-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr. )
To: rpg at SU-AI
CC: GLS at MIT-AI
[a] Next time the too many interrupts happens, it would help
if you could record the contents of these locations:
UNREAL, INHIBIT, NOQUIT, INTAR, INTAR+1,... UNREAR, UNREAR+1, ...
[b] Newio for TOPS-10 and related systems doesn't exist at all yet.
Clearly a way to specify multiple buffers will be necessary.
[c] I'd be happy to say yes, but our family will be moving during
the month of August, and I honestly don't know what precise state
our houses and furniture will be in at ther time of IJCAI.
I will look into it more and get back to you. (I presently
live with my parents and brother.)
∂30-Jun-77 1509 RPG
ured+6 from caie a,↑C to <flush>
∂03-Jul-77 1745 LIS NEW PSI.SAV AT ISIC
To: PSI.DIS[PUN,LIS]:;
The new psi is hopefully a bit easier to use. You no longer have to end
a line of typing with a space to be able to continue on the next line.
Instead, indicate that you are done by typing a period and a carriage
return as the only characters on a line. eg
The scene is a set of relations
.
If you forget to type the '.' and just sit there, PSI will remind you.
Also, if the parser-interpreter doesn't understand the sentence you typed,
it offers you the option of entering the LISP editor editing the old sentence,
or of typing a new sentence. eg
parser didnt like the following:
(The scene is and a set of relations)
Edit? Y
edit:
*
'Y' lets you edit; cr, N, or saying nothing for a few seconds lets you enter
from scratch.
Type ↑E while entering from scratch or exit from the editor with 'STOP'
and you get to start over. (If you were given the choice of editing something,
you will get the choice again.)
NOTE that when you are replacing a word that the parser didnt know, you
presently do not need the '.<cr>'.
∂06-Jul-77 1540 RPG %cxr
Until %cxr compiler bug is fixed for real,at 405133 there is a
jrst 6125 which should be a rot 7,-1
∂12-Jul-77 1311 JP here it is: FASFRKs!!
To: RPG, JP
file: nfork.fas[lib,lsp]
source: fasfrk.lsp[lsp,jp],newfrk.mid
cfork[(filnam ext p pn)] SUBR
forks to file. sets global lowfrk# to fork job#. returns this as
value in case you want to use it for something else
sfork[] SUBR
suspends your fork, returns job# of parent setting global upfork#
to this number.
msg[frk# sxpr]
mails sxpr to fork frk#. if sxpr is small it just sends it inside
the letter. if not it sends it via blt. You can send sxprs as large
as 5120 chars (~10pages of parens). beware: |..| atoms are screwed
up by losing maclsp
gmsg[]
sleeps waiting for message from anybody. Returns message as dotted
pair (frk# . sxpr)
waitmsg[msg frk#]
waits for message eq to msg from fork frk#. NILs in the right placess
act as wildcards (ie. any fork anay message). All other messages
are flushed.
j
∂20-Jul-77 1652 LIS via ISIC MAKING YOUR OWN MACROS IN INTERLISP
I CAN THINK OF 2 WAYS TO DO IT: ADVISE FAULTEVAL AND
FAULTAPPLY (SEE P. 16.1 IN THE LATEST MANUAL)
OR, IF YOU ARE NOT GOING TO TURN OFF DWIM, USE DWIMUSERFN (P 17.15 IN THE LATEST MANUAL)
∂20-Aug-77 0535 FTP:PRATT at MIT-AI (Vaughan Pratt)
Date: 20 AUG 1977 0835-EDT
From: PRATT at MIT-AI (Vaughan Pratt)
To: RPG at SU-AI
QUUX passed on to me your gripe about taking 0.5 hrs to cope with each
new version of CGOL. I've put your changes in as being translated
conditionally on SAIL being non-NIL. Thus to get a Stanford version
of CGOL, change the command "sail := nil" that you will find near the front of
AI:PRATT;CGOL >. (But don't make the change in CGOL >, as you did last time,
that came close to screwing me as I am in the habit of reaping my FN1 <
files frequently without thought, which assumes that no one else has been
generating FN1 > files that I didn't want - fortunately I
happened to have a relatively recent version of CGOL on MC that enabled me to
work out what changes you had made to CGOL >, so it turned out fine in the end.)
∂06-Sep-77 1407 PAM
DANNY RIBBENS
UNIVERSITY OF LIEGE
COMPUTER SCIENCE DEPT
B-4OOO LIEGE BELGIUM
send him the total maclisp package for tops-20
he's got a manual
∂14-Sep-77 1249 RPG
piano guy: 293-3769
∂23-Sep-77 1422 FTP:GLS at MIT-AI (Guy L. Steele, Jr.)
Date: 23 SEP 1977 1547-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
To: rpg at SU-AI
CC: (BUG LISP) at MIT-AI
For FASLOAD bug, try this patch and let me know if it
solves the problem:
at GTSPC1+3 change JRST GTSP1B to JFCL
This isn't most elegant, but should work.
at 31633 in maclsp.shr (OCT 22, 1977)
∂22-Oct-77 1749 RPG hunks
At rplacx + 4 skipe v.rset → skipa until cxr3 error checking code debugged.
∂24-Oct-77 1337 RPG
rod has the maclisp manual.
I understand you have my Maclisp Manual. If you are not using it could you
return it?
-rpg-
∂27-Oct-77 1346 BPM Guidelines for use of ISIE
To: PSI.DIS[PSI,BPM]:;
The rule for determining whether you can use ISIE or not is the following:
Run LD to get the load average and who is logged in from where. If the load
average is above 3.0 and there is someone logged in from the ARPA-TIP, then
don't use ISIE; otherwise, it's ok. Especially watch out for RUSSELL or
WHITAKER, e.g., if either is logged in and the load average is only 1.0,
don't start clanking and push it above 3.0. It's a good idea to check every
half hour or so between 5 am and 3 pm weekdays to see if you are still legal.
Other times shouldn't be any problem.
∂28-Oct-77 0148 RPG READ6C
READ6C should be defined in lisp >357. Otherwise re-do direct.>[aid,rpg]
using defsym.
∂28-Oct-77 0901 BPM Changing passwords at ISIE
To: PSI.DIS[PSI,BPM]:;
It is now possible to change ones password at ISIE. Use the command
SET PASSWORD <old password> <new password> <new password> .
∂02-Nov-77 1616 JP MACLSP meta-D directory feature
To: MACLSP.DIS[AID,RPG]:;
Subsribers of the HELP autodef package:
A new feature has been added to SAIL MACLSP to enable obtaining fast
directory listing using RPG's DIRECT fn. It permits use of >,#, and * as
wildcards. To access the package do when talking to MACLSP
βD <filespec> ;;; note: D not d!
where filespec is of the form filnam.ext[p,pn] and where ext,p,pn and the
syntactic delimiters can be omitted in the obvious cases. * wildcards are
allowed for for filnam and ext. If p or p,pn are omitted, they are
obtained from your current crunit device.
Ext can also be > and #. > obtains the largest numbered version, and # denotes
all numbered versions.
Ex:
*.#[lu,ser ;all files with numeric extension in [lu,ser
*.>[foo, ;the file with largest numeric ext in [foo,
*. ;all files w/o ext in crunit dir
...etc...
NOTE: No wildcards allowed in PPN!
∂03-Nov-77 1215 FTP:DEWOLF at WPAFB-AFAL Change of address
Date: 3 Nov 1977 (Thursday) 1514-EDT
From: DEWOLF at WPAFB-AFAL
Subject: Change of address
To: rpg at SU-AI
***** from Tim Finin *****
Hello Dick,
The name of our account here has been changed from
FINKE to DEWOLF. Send mail to me c/o DEWOLF@WPAFB-AFAL.
If you ever want to log into our 10 (for nostalgia
or kicks or whatever), you can do so by logging into WPAFB-AFAL
as 242,205 (do a "WHO DEWOLF" if you forget the PPN). The password
is the initials of the name of this place where I am really
sending this from. The do a CONNECT 13 to connect to our 10.
Everything you type will then be sent to our 10. After logging
out of our 10, you can get back to WPAFB by typing a control-A
(which is the excape char for the CONNECT program) and typing
a control-C. You can then log off of WPAFB (or whatever).
Did I ever tell you that the current version of
MacLISP still won't work for us? It (LISP 1303) thinks
that every FASL file (almost) is NOT in FASL format. Otherwize,
it seems to work. If you talk to GLS, perhaps you could bug
him about it for us.
Hope you, Kathy, and the dogs are doing well.
-Tim
p.s.: The COM area still has the same password (from the
rabbit book).
try tty1
∂08-Nov-77 1117 WLS EDIT loss
Dick --
Two problems: First, EDIT can't seem to find M_ZN4 below. Second, once
in the query loop for "function ... not found", there is no easy way to
escape. How about NIL causing EDIT to desist from questioning? The core
image is saved in MTEST[SY2,WLS]. This may be related to the Mysterious
Disappearance Bug......
Bill.
PPSAV follows: {RU MTEST[SY2,WLS] for more...}
--------------------------------------------------
← (PLIST 'M_ZN4)
(EXPR (LAMBDA (PR ZFN CF) (T_MSGS CF # #) (NCONS PR)))
← (EDIT M_ZN4)
function M_ZN4 not found?
(<function name> <file specifications>) : M_ZN4
function M_ZN4 not found?
(<function name> <file specifications>) : (NEW)
(NEW)
← (EDIT M_ZR1)
(M_ZR1)
← (EDIT M_ZN4)
function M_ZN4 not found?
(<function name> <file specifications>) : (M_ZR1)
(M_ZR1)
← (PLIST 'M_ZN4)
(EXPR (LAMBDA (PR ZFN CF) (T_MSGS CF # #) (NCONS PR)))
← (PLIST 'M_ZR1)
(EXPR (LAMBDA (PR ZFN) (T_MSGS CF # #) (NCONS PR)))
←
∂23-Nov-77 2025 FTP:gls@ai RABBITy things
Date: 23 NOV 1977 2324-EST
From: gls@ai
Sent-by: GLS at MIT-MC
Subject: RABBITy things
To: rpg at SU-AI
CC: gls at MIT-AI
Will send a copy of thesis when it becomes a TR (sigh).
RABBIT will treat LABELS functions in one of three ways depending
on how the names of the functions are referenced.
In the general case, it must cons up funargs and make
circular environments and the whole schmeer. In the best case
(only referred to as functions and not as variables), no consing
occurs at all; the cpompiler just keeps track of them,
and for each call to a LABELS function just adjusts the environment
to match the environment of the LABELS and then does a GOTO.
Halfway in between it must cons an environment, but need not
cons a pointer to the code into it as for a full funarg.
FASLAP/NCOMPL
Code in FASLAP at PUSHJ p,ioo+2 is now in line and uses
some funny address relocation. Could mean bugs later
∂02-Dec-77 1443 FTP:DEWOLF at WPAFB-AFAL ATN stuff
Date: 2 Dec 1977 (Friday) 1741-EDT
From: DEWOLF at WPAFB-AFAL
Subject: ATN stuff
To: rpg at SU-AI
Hi Dick,
I've been trying to get this message to you all afternoon, but
WPAFB-AFAL has been down. If you are desperate for this stuff,
(and need info or help), give me a call at home (217-344-6169).
I don't expect to be at CSL or on the machine next until approx.
2:00pm on monday.
,
$s
Hello Dick,
Firstly, let me tell you that we found the FASLOAD bug in
LISP 1305. It appears that it is in the code that you and
Quux wrote this August. Apparently, when FASLOAD tries to
get the last group of 6 blocks, the monitor raises an
END OF FILE condition (but still returns the last few blocks).
LISP notices this but doesn't check to see if any blocks were
returned. Anyway, it works when we changed it to load one
block at a time.
You are welcome to have my ATN stuff. All together there is about
230 blocks (128 words/block) of code. I'm not sure how much you
want, so I'll list all the relevant files here.
The format is:
file name size in 128 word blocks description
These files are in [1000,130,source]. The comprise the ATN system
(interpreter, compiler, support functions, etc.)
atn.lsp 50 atn interpreter
lex.lsp 22 morphology routines, etc.
parse.lsp 8 top-level function to apply an ATN
loaddic.lsp 10 dictionary manager
hatn.lsp 10 helpful auxilliary functions
atncompiler.lsp 30 compiler for ATNs
simplify.lsp 16 optimizer for ATN compiler
These files are in [1000,130,atn]. They comprise a hacked up (by me)
version of the Woods parser (syntax only!).
s.net 6 |
np.net 13 | ATN
vp.net 9 | networks
random.net 8 |
extra.atn 8 auxilliary functions called from nets
simple.dic 3 mini-dictionary
parse.ini 2 init file for parser
These files are on [5,720,source]. The contain macros needed
by above files.
define.lsp 28 define macro
lmacro.lsp 11 lisp macros
The .FASL versions of the .LSP files can be found in [1000,130]
for the first group and [5,720] for the last.
How do I get them to you? I see three basic options:
(1) Put them on a mag-tape and slip in the mail.
(is this fast enough?)
(2) Try to get them to WPAFB and then over the ARPA net.
One problem is that we have only a 1200 baud
line to WPAFB. The CONNECT program slows it down
to boot. A more serious problem is that CONNECT
tends to hang very often is either machine is loaded
(i.e. when the sun is up). If CONNECT is used, then,
it should be at night.
Also, we can't use FTP from WPAFB (no
network privledges there). I don't know if you can
run FTP from SAIL and suck up files from WPAFB (you
might give it a try as an experiment). If not, we
could always use MAIL to send the files from WPAFB
to SAIL. If you type a ↑G to the MAIL program at
WPAFB it will ask you for a file name and include
its contents in the body of the messsage.
(3) I could try to write a UNIX compatable tape here
with our PDP11 (which can run UNIX) and take it
to CAC, put it on thier machine and use FTP to
get it to SAIL.
How to use CONNECT to transfer files? The documentation
is in DOC:CONNECT.DOC (on our machine and probably also
on the one at WPAFB). The idea is that you get CONNECT
running on both machines, tell one:
RECEIVE <filename>
START
and tell the other:
SEND <filename>
START
Depending on where you are relative to the direction of
transfer, you have to do these in the proper order and
may have to type a character to get it going.
If you want to use CONNECT, I'll try to send more coherent
instructions.
Let me know what you want to do. I'm happy to help.
- Tim
p.s. I told the MIT INQUIRE program to have any network mail
sent to me at MIT-?? forwarded to DEWOLF@WPAFB-AFAL. Thus,
if its any easier, you can mail to FININ@MIT-AI (or MC, etc.).
I usually check WPAFB-AFAL for mail every weekday.
AT gethgh+16 jrst patch
patch: getsts 0,r
tro r,1000
setsts 0,(r)
move r,sgappn
jrst gethgh 17
r = 11
gethgh+16 = 1305
patch = 6274
sgappn =1412
∂12-Dec-77 1333 FTP:DEWOLF at WPAFB-AFAL
Date: 12 Dec 1977 (Monday) 1631-EDT
From: DEWOLF at WPAFB-AFAL
To: rpg at SU-AI
Hello Dick,
1 - The name of the street one block west of Goodwin in Mathews.
2 - Those hackers using ANs in your group might be interested
in the file (on our 10) ONR:NAVY.DIC which is a dictionary
of approx. 600 words.
3 - Haven't had a chance to check out the ATN compiler bug, but
hope to now.
4 - The line between our 10 and WPAFB-AFAL is now line 30.
-tim
∂15-Dec-77 1907 DCO datamedias
To: RPG, WLS
(CHECKDM), defined on DM.LAP[ARC,DCO] returns T if your terminal
is a datamedia, and NIL otherwise.
∂21-Dec-77 0312 JJ
the dialogue for this is page 3 of dials[is,jj]
the names for the slots and their inverses are:
ASSERTIONS (no inverse)
((CASES CASEOF)
(DEFINITION DEFINITION-OF)
(BINDINGS BINDINGOF)
(EXITS EXITOF)
(BTYPES BTYPEOF)
(CONDITION CONDITION-OF)
(ARG1 ARG1OF)
(ARG2 ARG2OF)
(ARG3 ARG3OF)
(ARGS ARGOF)
(FIELDS FIELDOF)
(IARG IARGOF)
(#IO-DEVICE #IO-DEVICE-OF)
(INSTANCEOF INSTANCES)
(ALTS ALT-OF)
(FORMAT FORMAT-OF)
(STEPS STEPOF)
(PROC PROC-OF)
(ELEMENT ELEMENTOF)
(NAME NAMEOF)
(RESULT RESULTOF)
(DATA DATA-OF)
(SIZE SIZE-OF))
∂19-Dec-77 1259 RPG fx arrays
mkfxar -1,,0 in a # words in tt get array object in return.
look in defns under format of arrays pg 9.
also in file array where mkfxar is.
∂20-Dec-77 1445 RPG
KUMAR 493-3158 340 VENTURA AVE APT 22
∂05-Jan-78 2109 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) HISEG CRAP
Date: 6 JAN 1978 0011-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: HISEG CRAP
To: rpg at SU-AI
CC: gls at MIT-AI
I suggest loading this program into the loseg first:
(LAP THE-BUFFER SUBR)
(BLOCK 43) NIL
Then do (SETQ THE-BUFFER (GET 'THE-BUFFER 'SUBR)).
Then set up for hiseg loading and load the rest of the crap.
Whenever the pure code wants to reference the buffer
(e.g. make an AOBJN pointer into it) it should reference the
special variable:
(MOVE TT (SPECIAL THE-BUFFER))
(HRLI TT -43)
and so on. That's the best kludge I can think of.
Derek, you could ty something like this. The stuff at info on page
3 or 4 in screen needs to be in the lowseg, since it's a data block.
-rpg-
∂14-Jan-78 1413 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) OS/S1 and LISP and others
Date: 14 JAN 1978 1713-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: OS/S1 and LISP and others
To: pmf at SU-AI
CC: GLS at MIT-MC, rpg at SU-AI, jbr at SU-AI
It occurs to me that a highly desirable characteristic of an operating
system would be that maximal attention is paid to allowing routines
written in various languages to call each other freely. This can
pose several problems for language implementations which either
have extensive run-time support systems or are interactive and so
must support dynamic interaction. LISP falls into both categories.
To see the problem with clashing run-time systems, consider the PDP-10
UUO feature, and trying to get FORTRAN and LISP to coexist.
As for dynamic interaction, LISP in principle allows the user to
call for the invocation of any extant function in the system.
MacLISP supports this by providing its own idiosyncratic run-time
linking loader. Much as I hate to admit it, Multics did have somewhat
the right idea here, allowing nearly any function to invoke any other.
In order to do this, the system has to have linking
and uuo-handler type support within it. Also, being able to
write procedures which are callable both from "command level" and
from programs is a good idea in principle, though the particular
arrangement in Multics (different syntaxes for the two cases)
made it difficult to exploit this thoroughly. LISP of course does
this all the time within its world, but it would be nice to have it
work among all languages.
To prevent run-time systems from clashing, I thinm one
must avoid "fixed" resources. For example, with I/O
channels, one needs to be able to say "cons me up a channel and
tell me which one" a la Tenex JFN's, rather than only "open channel 4".
(The horrid word "capability" springs to mind here. Sigh.
But this notion allows one to think of "consing up" fresh objects
and then passing them around from procedure to precedure.)
One also needs some interfacing standards for procedures which are
both flexible and efficient. See VAX documentation for
an effprt at this which is not a complete loser (though it almost is).
The idea of the CALL instruction pushing a random zero word bites the
bag for a number of reasons,, and the arg pointer/frame pointer
mechanism may be too restrictive for LISP (though it will
probably be enough for PL/I and PASCAL and FORTRAN); but at least
they tried. The "standard data formats" for argument transmission
are not a total loss either, I guess.
Any kind of dynamic linking feature must be flexible enough to
support linking not only of code but also of data. When a new
procedure is linked into an existing group of LISP routines,
one needs to be able to identify certain atomic symbols,
list structures, etc. for use by the new routine.
These are language-specific, so maybe each
"segment" needs an intiialization routine that gets run when
the segment is linked in.
∂09-Feb-78 1857 FTP:HIC at MIT-MC (Howard I. Cannon)
Date: 9 FEB 1978 2157-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RPG at SU-AI
CC: HIC at MIT-MC
Here is the fix to FRETURN:
* means line has changed, # means line has been added:
*FRP2: SKIPE B,ERRTN ;BREAK UP A DOMINEERING ERRSET
;a skipe b,catrtn has been deleted from here
FRP2A: CAIL F,(B)
* JRST FRP4
MOVEI TT,FRP1
JRST BKRST0
#FRP4: SKIPE B,CATRTN ;BREAK UP A CATCH
# CAIL F,(B)
# JRST FRP3
# MOVEI TT,FRP1
# JRST BKRST0
Also, FRP3QA+6 ↔ FPR3QA+13
∂13-Feb-78 1455 CCG psi
To: PSI.DIS[PSI,BPM]:
I received final word from Stanford that I won't get a tenure offer.
This means I'll be leaving sometime between now and September 1979.
I don't know when and where I'll go, yet, but I intend to facilitate
each student's graduating within a reasonable time frame, with adequate
financial,computer, and advising support provided. So don't worry.
PSI will live on, and the book is still the next step after we complete
our current set of dialogues.
Cordell
p.s. Believe it or not there has been a grass-roots movements for weekly
meetings on Psi, to discuss research problems and progress. I'm in favor.
How are wednesdays?
∂23-Feb-78 1655 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) PRINTA
Date: 23 FEB 1978 1955-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: PRINTA
To: rpg at SU-AI
CC: (BUG LISP) at MIT-MC
It's documented in the code: B,C,T,TT,R must be
saved by the TYO routine (whose address is in the RH
of R), and PRINTA saves AR1 and AR2A so that the TYO routine
can use them.
∂21-Mar-78 0002 JJ
(WHATIS x) x is a data "what should x be" or "how should i compute x"
whatis differs from structure in that X is a data which is to be computed by
the program.
At ldrihs+5 =1447
ldrihs+5: jrst patch
patch: = 6306 move t,d10nam (move 6,1014)
lsh t,-6 (lsh t,-6)
setnm2 t, (setnm2 6,)
hrri r,40000-0 (hrri 11,377777)
jrst ldrihg+6 (jrst 1450)
∂07-May-78 0206 LIS NEW PSI
YOU CAN NOW GET THINGS EVALUATED IN YOUR FORK BY TYPING !!!, EG
PSI: XXXX
USER: !!! (HELP)
.
ALSO, THE ATOM !ENGLISH WILL CAUSE YOUR FORK TO BE REINVOKED TO RECOMPUTE
THE ENGLISH FOR THE PRESENT QUESTION, EG
PSI: XXX
USER: !ENGLISH
.
PSI: YYY
∂11-May-78 1847 RPG Fleming
Fleming M. Oliver
(408)734-8771
213 Wedell Dr.
#12
Sunnyvale Ca. 94086
CS/EE
-rpg-
∂01-Jun-78 1517 PAM
408-742-1994 FLEMING CS/EE work phone (Lockheed Sunnyvale)
GLS@MIT-AI 05/27/78 17:09:59 Re: Cretinous Stack Groups
To: NIL at MIT-AI
CC: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI
Here is a proposed theory of "stack group/cretin" interactions.
This was worked out by DLW and me, with reference to the SL5 paper
in this month's CACM, starting also from the existing LISPM SG
implementation. DLW worked out quite a bit of this, but I may take
liberties in emending it, so any inaccuracies are my fault.
Because I am not fond of "stack group" as the name of these entities,
I'll call them "cretins", and also choose completely terrible names
for the proposed functions, hoping that they will not become entrenched,
because I haven't given much thought to names that would meaningfully
reflect their high-level semantics.
A cretin must contain a certain amount of state; it has the control
stack and binding pdls for a process, and possibly much other stuff.
Here I will not talk at all about the binding disciplines, but only about
the control.
Let one slot of the state of a cretin be known as the "resumer".
This slot may be empty, or may point to another cretin, in which
case that cretin is presumably in a suspended state, waiting for a value
to carry on with.
Now when one cretin (a) wants to transfer control to another (b), it must
pass a value to it; it may or may not also want to pass a resumption
point. If it (a) does, it may want the resumption point to be itself (a),
its own resumer (the resumer of a), or yet a third party (c).
Now if a does choose to pass a resumer to b, then it will be stored
in b's resumer slot for later reference. The resumer slot of b must
be empty for this to occur (stipulation, to avoid losing information
and allow error-checking). It is permissible, however, not to pass
b a resumption point when b'd resumer slot is empty; in this situation
b must be smart enough not to use its resumer slot.
We thus propose primitives of this sort:
(CRETIN-GO value cretin resumption)
This transfers control to <cretin>, giving it <value>,
and passing it <resumption> to be put in its resumer slot.
Error if <cretin>'s resumer slot is not empty.
(CRETIN-GO value cretin)
Transfers control to <cretin>, passing no resumption point.
(CRETIN-JRST value cretin)
Transfers control to <cretin>, passing it my resumer as a resumption
point, and also clearing my resumer slot. If I have no resumer (my slot
is already empty), then <cretin>'s slot will be made empty also (?).
(CRETIN-PUSHJ value cretin)
Transfer control to <cretin>, passing myself as the resumption
point.
(CRETIN-POPJ value)
Transfer control to the cretin in my resumption slot (error if
none), passing no resumption point.
(MY-RESUMER)
Returns my resumer, and as a side-effect clears my resumer slot.
Useful for weird hacks.
(HIS-RESUMER cretin)
Returns the resumer slot of <cretin>.
(CLOBBER-HIS-RESUMER cretin resumption)
Clobbers <cretin>'s resumer slot. NIL (i.e. ()) means make empty.
CLOBBER-MY-RESUMER??
Some of these are incredibly dirty, and others are more disciplined.
It is not hard to show that if things are initialized properly,
and only CRETIN-PUSHJ and CRETIN-POPJ are used, then nothing bad can
happen - no errors should be able to occur undetected. Maybe
this also holds if CRETIN-JRST is added - this is intended as the
equivalent of the "JRST hack". The otherrs allow for completely
general hair, such as may be necessary for time-slicing or distributed
processing kinds of deals.
Now transferring control to another cretin suspends the current one,
putting it into a state that awaits a value. When eventually someone
else transfers to it, that value is returned as the value of the call
to CRETIN-PUSHJ or whatever. Multiple-value versions of all of
the above can be worked out.
∂05-Jun-78 0031 GLS at SU-AI (Guy Steele) This note is an attempt to summarize the discussion JONL and I
Date: 5 Jun 1978 0028-PDT
From: GLS at SU-AI (Guy Steele)
Subject: This note is an attempt to summarize the discussion JONL and I
To: nil at MIT-MC
CC: bug-lisp at MIT-MC, bug-lispm at MIT-AI
and others had about the nature of variable bindings and references
in NIL. If I have made any mistakes, or failed to represent the
consensus of opinion, please let me know. I am going to try to
mention the alternatives that were considered, and also contrast
NIL, MacLISP, LISP 1.5, and SCHEME.
"Variables" in NIL are used for at least three different purposes:
[1] as the names of "globally" defined procedures, e.g. CONS.
[2] as "local" names of data objects.
[3] as "global" (i.e. dynamic) names of data objects.
Now the names of functions are normally thought of as being
"constant", while global names of data objects are though of
as varying over time. It may be a useful notion, we have said,
to allow binding of global function cells. Conversely, LISP 1.5
had a notion of a globally constant data object name (APVALs).
Now one problem with APVALs was that they were checked for BEFORE
the a-list was searched -- there was no way to "shadow" them.
Besides the issue of binding function names, there is also the
issue of wanting to treat functions per se as data objects.
In any case, we assume there are three sorts of variables (at least
-- one could for example complete the symmetry and imagine local
functional variables as well as global ones). Now if gross screws
are to be avoided, there must be a way for the user to precisely
specify which variable is to be bound and which variable is to be
referenced at any point in his program.
In MacLISP, functions are not really first class data objects.
The model is that there are two distinct "evaluation contexts"
for names. One is the function position of the combination,
and the other is essentially all other places. In the function
position, an atomic symbol is interpreted as a reference to
the function cell, unless undefined, in which case the dynamic
value is used (modulo EVALPUNT, and the fact that a function as such
cannot live in a value cell, but only a symbol). I have no idea
what happens when you write (FUNCTION symbol) in the function
position, either interpreted or compiled. There is no good way
to refer to a function object in a local or dynamic variable
from the functional context -- instead, the FUNCALL construction
must be used.
In non-functional contexts, the "function cell" can be referred
to by writing the construct (FUNCTION symbol), and a plain atomic
symbol refers to a dynamic value. (MacLISP has no consistent notion
of a local variable. The interpreter cannot handle them correctly.
The compiler assumes that variables are by default local, leading
to a non-robustness, because by default interpreted and compiled
versions of the same program are likely to have radically differing
behaviors.)
MacLISP has only one kind of variable binding (dynamic, local
being excluded as above). There is no way to bind a function
cell.
In SCHEME, there is (or ought to be) a consistent notion of
a global function cell, a dynamic value cell, and local variables.
SCHEME provides no facility for binding function cells; the model
is that the function cells provide the outermost "contour" for
the lexical environment. There is only a single evaluation context
for names. In that context, one writes an atomic symbol to refer
to a lexical variable, and (FLUID symbol) to refer to a dynamic
variable. There is no way as such to refer directly to a global
function cell, because a function cell can always be lexically
shadowed. This is seldom a problem for user programs, but can
pose problems for macros.
For binding, SCHEME distinguishes fluid bindings from lexical ones.
There is no way to bind a global function cell. Thus function cells
can be shadowed lexically but not dynamically.
I believe what was decided, at last meeting, for NIL was
that the notion of two distinct "evaluation contexts" for names
be preserved, the model being that function names are usually thought
of as constants in some sense. However, there may be a way
to shadow such definitions dynamically by binding the function
cell. On the third hand, such names cannot be shadowed lexically.
Thus, in the "functional context", only a small class of expressions
are legitimate: atomic symbols (referring to the global, possibly
dynamic, function cell), and a few special expressions such as
LAMBDA-expressions. (Are macro calls to be allowed to work in functional
context?) There is no way to refer to a dynamic variable or a local
variable in function context -- one must use FUNCALL, as in MacLISP.
(It would be possible to define constructs which would legitimately
refer to such other variables in function context, but it is not
clear whether this is better or worse as a user syntax than FUNCALL.)
In other evaluation contexts, the three kinds of variable can be
referred to by the constructs:
symbol [local or dynamic variable]
(DYNAMIC symbol) [dynamic variable]
(FUNCTION symbol) [global function cell]
Now as we discussed, there is a set of nasty cases where an ambiguity
arises from the fact that an atomic symbol can be viewed as either
a local or a dynamic variable, and so one must have a way to force
the dynamic interpretation; hence the provision of the DYNAMIC construct.
There is still some doubt in my mind as to whether we should simply
tell the user always to use the DYNAMIC construct, which always but
always works (in which case a macro character similar to ' for QUOTE
should be provided), or tell him it mostly works not to use it
and describe the kind of hairy situations where it will lose.
Now it is interesting to note some similarities and differences between
the NIL proposal and the SCHEME proposal (which does not fully exist
either as an implementation). Both implicitly acknowledge the existence
of three distinct kinds of variable in terms of which the user may wish
to think. Both try to squeeze the three kinds into two sorts, because
the user may wish to mix sorts in his mind occasionally. In SCHEME,
the global functional and local (lexical) types of variables are allowed
to be confused: atomic symbols are conditionally treated first
as local, and then as global functional if that fails. This seems to
be good for styles of programming in which it is likely that globally
defined functions will be referred to as objects to be passed as
arguments; it was of course just such styles that SCHEME was in part
designed to explore. The dynamic variables are kept apart, because
they behave differently from the other two. (The relationship between
global "data" variables and global "function" variables is not apparent
in SCHEME because there is no facility for dynamic binding of global
functional variables. In writing "The Art of the Interpreter" I first
realized how important this notion might be to SCHEME.)
In the NIL proposal, the three kinds of variable are also squeezed into
two, but using a different division: here it is the global functional
which is the loner, and the other two are confused. This suits a style
of programming in which functions are seldom treated as data objects,
and so it is mostly useful to separate names for functions from names
for other kinds of data objects. It may be useful to confuse local
with dynamic variables for some purposes. The lookup discipline is
(as I understand it) to check for a local definition first, and if
that fails, use the dynamic value cell.
Both proposals have the serious disadvantage that whichever kind of
variable is confused with local variables can be accidentally shadowed
by a lexical variable (note the similarity between the conditional
lookup disciplines in the two proposals as I have (I hope accurately)
described them). This poses little problem to the user, but can
make things tricky for macros which cannot see their precise binding
contexts. In each case this necessitates the introduction of a special
construct for eliminating the confusion. In the case of NIL, it is
the dynamic construct; I am considering likewise proposing the
FUNCTION construct for SCHEME to eliminate the analogous ambiguity.
As may perhaps be well known, I still happen to favor the SCHEME
proposal slightly, because it simplifies the description of the language
(requiring only one kind of name evaluation context) while maintaining
that standard "Cambridge Polish" functional notation for the simple
cases; i.e. (CONS A B) means applying the function names by "CONS"
to two arguments named by "A" and "B". The FUNCALL notation is not needed.
On the other hand, for those used to using one name as both the name
of a function as as the name of a data object (and there are often
good reasons for this -- e.g. LIST and EXP!), the separation inherited
from MacLISP contained in the NIL proposal can be valuable.
In conclusion, I repeat what I said earlier: the NIL proposal, the
SCHEME proposal, and yet other possibilities are each appropriate to
a certain style of programming. Certainly the choice of model and
discipline will have the effect of encouraging certain styles of
programming and discouraging others. This choice is therefore not
to be made lightly. I favor a rather liberal approach, namely to
try to encompass as many styles comfortably as is possible without
conflict, other things being equal.
Now some issues that have not yet been touched upon here or in our
meetings include that of local functions, encompassing both
closures of various sorts and LABEL or LABELS or whatever. I think
it is true that the MacLISP handling of LABEL is not acceptable.
What can be done to fix this? Also, I recommend the LABELS syntax
as being analogous to LET in allowing mutually recursive definitions;
indeed, it is a subset of LETREC (cf. Landin). A useful borderline
case between the use of a LABELS-like construct and packages is the
construction of OWN variables by some such piece of code as:
(PROG (OWN0 OWN1 OWN2 ...)
(DEFUN FUNNYFN1 ...)
(DEFUN FUNNYFN2 ...)
...)
Gerry and I have been considering simply defining DEFINE to be a macro
which expands into an ASET', i.e. not to hide so carefully the fact that
it simply clobbers afunctional value into a certain variable (though the
user can ignore this fact mostly if he likes):
(DEFINE FOO (X Y) BARF) => (ASET' FOO (LAMBDA (X Y) BARF))
Do we similarly want to simply define DEFUN as a macro defined in
terms of FSETQ or SETQ or whatever?
-------
∂05-Jun-78 1929 GLS at MIT-MC (Guy L. Steele, Jr.) Summary of binding
Date: 5 JUN 1978 2229-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: Summary of binding
To: NIL at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG lispm) at MIT-AI
I forgot to mention the suggestion that the declarations
as to binding class of variables be placed as declarations of some sort
at the head of the body, rather than inserted as funny keywords
in the lambda-variable list itself. This is similar to the way
the LISP Machine has come to use CHECK-ARG rather than the type
keywords. On the other hand, declarations of DO variables still look
pretty strange. On the third hand, keywords in DO variable lists
would look even crazier, maybe.
∂07-Jun-78 1333 GLS at SU-AI (Guy Steele) Named PROG Feature
Date: 7 Jun 1978 1330-PDT
From: GLS at SU-AI (Guy Steele)
Subject: Named PROG Feature
To: NIL at MIT-MC
CC: bug-lisp at MIT-MC, bug-lispm at MIT-AI
It has been suggested that a feature be introduced into LISP for
naming PROGs. This would permit returns out of multiple levels
of PROG, allow more precise specification of non-local GOs,
and effectively provide the "lexical CATCH" notion. Here I attempt
to gather together all the proposals for possible syntaxes for this
feature. I would like to reach a prompt decision on this feature,
so speedy feedback would be appreciated.
The basic notion is that a PROG can be assigned a name by which
RETURN and GO forms can refer to it. As with CATCH, there is the
issue of whether it should be permitted to compute the name.
(I am inclined to say "no", given that the feature may be intended
to be more static in nature than CATCH).
I believe that two suggestions have been put forward for the syntax
of named PROGs:
(1) (PROG <name> ( <-vars-> ) ...)
(2) (PROG ( <-vars-> ) <name> ...)
I happen to favor (1), just because the name is a little easier to see.
One feature of (2) is that the name looks like a tag, which is both an
advantage and a disadvantage.
Possible syntaxes for RETURN are:
(1) (RETURN <name> <value>)
(2) (RETURN <value> <name>)
where in each case the <name> can be elided, meaning the immediately
containing PROG, as usual. These both have the disadvantage of
conflicting with existing LISPM multiple-value syntax. A more
off-the-wall possibility is:
(3) (RETURN <value1> ... <valuen> . <name>)
where <name> can be elided. This has the useless elegance that
() means the immediately containing PROG, and so is somewhat similar
to CATCH. It has the severe inelegance of introducing dot notation.
Another possibility is just introducing a new keyword for non-local
RETURNs:
(4) (NLRETURN <name> <value1> ... <valuen>)
Similar choices exist for GO:
(1) (GO <name> <tag>)
(2) (GO <tag> <name>)
(3) (GO <tag> . <name>) [this hardly seems justified!]
(4) (NLGO <name> <tag>)
While there is no problem with multiple-value returns, there is one
with computed GOs. Even without the named PROG feature, I would
lean toward an incompatible change, and introduce a special
COMPUTED-GO primitive, which could have its own funny syntax as
desired and would solve the problem of having a tag in a variable
FOO and wanting to say (GO FOO) -- the usual contortion (GO (SYMEVAL 'FOO))
will have insurmountable interactions with local variables in NIL.
-------
∂14-Jun-78 1442 LIS
∂14-Jun-78 1415 BURTON at BBN-TENEXD Re: Volleyball
Date: 14 Jun 1978 1714-EDT
Sender: BURTON at BBN-TENEXD
Subject: Re: Volleyball
From: BURTON at BBN-TENEXD
To: BPM at SU-AI
Cc: Burton
Message-ID: <[BBN-TENEXD]14-Jun-78 17:14:30.BURTON>
In-Reply-To: Your message of June 14, 1978
Yes I am interested. However just when I will be arriving is very up in
the air. Today it looks like December is a good bet. So definitely
put me on the roster (unless you are limited as to number you can list)
and I'll let you know when things get more firmed up.
Thanks for the invite.
dick
To make a directory at MIT do
:print rpg;..new. (udir)
Date: 10 Oct 1978 0307-PDT
From: BAG at SU-AI
Subject: New bit instructions
To: s1arch at SU-AI
I propose we add some bit manipulation instructions.
Henceforth a string of bits will be known as a "bag".
Instruction Description
BAGBYTER BAG to BYTE Reversed
HANDBAG 5 digit no. → BAG
MAILBAG Message processing instruction
SCUMBAG Scalar unsigned multiply to bag
HUMBAG Seasonal use only (usually follows branch-and-hang)
PAPERBAG Dump bag to LPT
BARFBAG Symbolic debagger
BAGBOY Call for manual intervention
BAGEL Annular rotate
GRABBAG Generate random bitstring
GARBAGE Apply Rivest encryption to bag
BAGGAGE Return half-life of bag
CRIBBAGE Play with bag
BAGPIPE Interlock bag processor pipeline
SANDBAG Check bag range and raise number of bits
FEEDBAG Block input to bag
MOVMBAG Move many bags
OVERBAG Test for bag overflow condition
Sample program showing high-level extensions to PASCAL to access
these instructions:
program BAGGIT;
var GREEN, RED : bag;
bagin
while BAG <> EMPTY do
with BAG do
bagin
BYTE(BAG);
EAT(BAGEL);
for ITS in BAG do
let CAT = OUT(BAG);
bagend;
cobagin
bag1: while true do REBAG(BAG1);
bag2: do DEBAG(BAG1) until HELL_FREEZES_OVER_
cobagend;
bagend.
Due to the extreme importance of these new instructions, the S-1 processor
is hereby renamed the BAG-1. The assembler and simulator will of course
be called BAGASM and BAGSIM. The operating system will be known as BAGOS.
The BAG-1 mark II memory will be constructed exclusively from 64K heavy-
duty bags, with double-bag detection and single-bag correction (SAGBAG).
I also have this idea for a new associative memory, called SPAM for SPastic
Associative Memory. Example of call, SPAM.SPAM.SPAM.SPAM.SPAM.SPAM...
More details later.
∂20-Nov-78 1157 RPG
jj 201 582-7262